[Previous] [Next] [Index] [Thread]

Re: What is "certificate"? (was: what are realistic threats?)

>From: datkins
>To: Hapeman Dale
>Cc: 'www-security'
>Subject: Re: What is "certificate"? (was: what are realistic threats?)
>Date: Monday, October 10, 1994 7:42AM
>
>I'm late getting into this discussion; what can I read to get up to speed
>on all this?

My reference is to CCITT X..509.  It is an ISO standard (The 1988 version 
 was called the Blue Book).  It can be bought (sorry) from the National 
Technical Exchange Service. See their Anonymous FTP server at 
ftp.fedworld.gov or call (703) 487-4650.  Try the PEM RFC's also (1422-1424 
is a guess).

>>
>> How are these bound together?  Because the issuer of my certificate signs 

>> the bits that make up my certificate.  My certificate can not be altered
>> without invalidating my issuer's signature.
>>
>> Now, you can validate my signature using my public key and know it came 
from
>> me because the issuer of my certificate says that that public key belongs 
to
>> me. The only thing my issuer has effectively "certified" is that I am the 

>> person who signed whatever it is I sent you.  You can verify the issuer's 

>> signature on my certificate by gaining access to his certificate (and his 

>> public key).
>>
>> Why should you put am credence in my issuer's signature?  Somebody issued 

>> and signed his certificate verifying that his public key (the one you 
used
>> to verify his signature) does indeed belong to him.  That somebody
>> "certified" that he is really the person who used the public key that 
signed
>> my certificate.
>
>This is all fine, but I seemed to have missed how the issuer verifies the
>contents of a document.  It would seem that would become the weak link in 
all
>this.  Not that I cant trust my issuer, but how does an issuer, with
>confidence(100%), validate a document?  If an issuer cant give you that
>degree of confidence then how can you ever trust the certification?
>Another foolish question is what is an issuer.  What entity is it?
>
You have hit on the essence of my point.  The issuer of a certificate makes 
absolutely no assertion with respect to the validity of a document (or any 
statements made in a document, or credit history, etc.).  The issuer is only 
verifying that THIS public key material  does indeed belong to the person 
named in this certificate.

Who or what the issuer is is determined by the infrastructure proposed by 
the people who do the proposing :-) .  This is what needs to be decided. 
 What method of certificate validation infrastructure will be used for 
secure (authenticated) WWW exchanges?  Here are some possible examples:

     1) Joe Schmoe could issue you a certificate (if the cryptography 
allowed this).  Joe's friend could issue him his certificate, Joe's friend's 
friend could issue Joe's friend's certificate. And so on.  Someone else 
trying to validate your certificate becomes a process of them trying to find 
some issuer in your path that they trust.  There is no assurance that this 
is possible.  I think this is the method used by PGP.

     2)  You could have a "Certification Authority".  This entity would 
issue all of the certificates in your group (company, city, house, etc.). 
 Your Certification Authority (call it "level one") would certified by it's 
Certification Authority (call it "level two").  The level two Certification 
Authority would issue all of the certificates for all of the level one 
Certification Authorities in a larger group.  And so on.  This creates a 
formal higherarchy of Certification Authorities (CA's).  Someone else trying 
to validate your certificate becomes a process of them trying to find some 
issuer in your path that they trust.  Since there is a formal tree of CA's, 
it becomes much more likely that they can find a CA they trust.  In fact, a 
CA in their higherarchy MAY be a CA in your higherarchy. If not, CA's can 
"cross certify"  each other. In this method, there are multiple 
higherarchies with no guarantee of a common point.  I think this is the 
method used by PEM.

     3) The last case just guarantees a common point in the higherarchy, 
 usually the top.  There is ONE higherarchy (tree), and the top is called 
the ROOT.  There are rumblings that the Post Office might be that ROOT (and 
all of the tree to)!

This brings us back to the point.  You will go to the Post Office to get 
your private key and your certificate.  The Post Office will verify that you 
are you and sign your certificate.  Just like when you go to the Post Office 
to get a passport - you show them your Drivers License and Birth Certificate 
to prove that you are you - not that you will not smuggle dope.

>drex
>
>        ---------------
>        datkins@unm.edu 
                                        "tight-lines"
>        CIRT-ACS  University of New Mexico
>        ----------------------------------

Dale Hapeman